COMMENT ⊗   VALID 00047 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00005 00002	@Make[Report]
C00009 00003	@BEGIN<TitlePage>
C00011 00004	<<here>>	Things to merge in:
C00019 00005	@Chapter[Motivation]
C00035 00006	@SubHeading[Constraints on Definition of Analogy]
C00040 00007	@SubHeading[Issues Addressed]
C00043 00008	@SubHeading[(Meta)Purpose]
C00046 00009	@SubHeading[(Meta-)Organization]
C00047 00010	@Chapter["Behavior" of Analogy]
C00049 00011	@Section[Informal Scenarios]
C00059 00012	@SubHeading[Something else is needed]
C00063 00013	@SubHeading[More Examples]
C00067 00014	@SubHeading[@i{Post Mortem} on Binary Analogous]
C00070 00015	@Section[@i{Depth} of an Analogy]
C00075 00016	@Chapter[Formal Description of Analogy]
C00079 00017	Note second that, while this description may be adequate, and sufficient,
C00082 00018	<<<here: merge this in>>>
C00085 00019	@Section[Arguments to "Analogous"]
C00095 00020	@SubHeading[Just Linguistic Problem?]
C00098 00021	@SubHeading[Why So Seductive?]
C00106 00022	@SubHeading[Other Failings of Binary Form]
C00110 00023	@Section[Theory or Object?]
C00117 00024	<<here>>
C00125 00025	@Section[??? where does this go? Reformulation Issues]
C00127 00026	@Chapter[Simple Analogy Examples]
C00131 00027	@Section[Case I - Formal]
C00139 00028	@Section[Case II - Informal]
C00142 00029	@Comment{ Arthur/Beth cases }
C00147 00030	@SubHeading[What are other arguments to @i{Analogous}?]
C00148 00031	@Chapter[Mapping]
C00149 00032	@Section[Feature to Feature Mapping]
C00157 00033	@Section[Symbol to Symbol Mapping]
C00161 00034	@Section[Summary of Mapping Approach]
C00167 00035	@SubHeading[Difficulties]
C00173 00036	@SubHeading[Other Issues: Reformulation]
C00178 00037	@Chapter[Commonality]
C00180 00038	@Section[Common Theory]
C00184 00039	@Section[Common Class]
C00189 00040	@Section[Summary of Commonality Approach]
C00195 00041	@SubHeading[Other Issues: Learning]
C00198 00042	@Chapter[Answer: Common theory + Mappings]
C00201 00043	@Chapter[Remaining Issues]
C00205 00044	Satisfies properties of analogy?
C00207 00045	@Chapter[Acknowledgements]
C00208 00046	@CHAPTER[Notes]
C00218 00047	@Unnumbered[References]
C00233 ENDMK
C⊗;
@Make[Report]
@Device[DOVER]
@LIBRARYFILE<SPECIALCHARACTERS>

@Comment< @Case{Device,	FILE "@Style(Endnotes)",
		PAGEDFILE "@Style(Endnotes)"} >

@Modify[Verbatim, Break Before]
@Modify[Description, Spread 0, Spacing 1.3, LeftMargin +10, Indent -10]
@Modify[Quotation, Indent 0]
@Modify[Itemize, Referenced <@#>]
@Modify[Enumerate, Referenced <@#@;#@:.@1@,@#.@a@,@#.@i>]
@Modify[Appendix, Numbered <@A.>, Referenced <@A>]
@Modify[Equation, FaceCode T]
@Comment{ Brian said this would work... Ha!
 @Modify[NoteCounter, Referenced <@#>] }
@Style[References=STD Alphabetic]
@DEFINE[Aside=NoteStyle, LeftMargin -16, Indent 0]
@DEFINE[SubAside=Quotation,Font SmallBodyFont,FaceCode I,Spacing 1,Spread 0.5]
@DEFINE[Subsubsection,Use HdX,Font TitleFont3,FaceCode I,Above .3inch,Centered]
@DEFINE[ENUM0=ENUMERATE, NumberFrom 0, SPREAD=0, Above=0.3 line, Below=0.1 line]
@DEFINE[ENUM1=ENUMERATE, SPREAD=0.1, Spacing=1, Above=0.3 line, Below=0.1 line]
@TEXTFORM[BEGENUM1 = 
	"@BEGIN<ENUMERATE, SPREAD=0.1, Spacing=1, Above=0.3 line, Below=0.1 line>"]
@TEXTFORM[ENDENUM1 = 
	"@END<ENUMERATE>"]
@DEFINE[ITEM1=Itemize, Spread=0.1, Spacing=1, Above=0.3 line, Below=0.1 line]
@DEFINE[DESC1=Description, Spread=0, Spacing=1, Above=0.3 line, Below=0.1 line]
@DEFINE[TEXT1 = TEXT, USE NoteStyle]
@Define[NoIndent,Continue Forced,Break Around]

@EQUATE[YY=R]

@Counter[EquationCounter, Numbered <(Facts @1)>, Referenced <(Facts @1)>,
IncrementedBy tag, INIT 0]

@Comment{ Now to keep from Breaking in front of chapters. }
@DEFINE(HdChap,Use HD1,PageBreak Off,Above .6inch)
@Counter(Chapter,TitleEnv HdChap,
	ContentsEnv tc1,Numbered [@1.],IncrementedBy Use,Referenced [@1],Announced) 
@Comment{How annoying!   Without this, the section numbers don't get reset!
	Note this is exactly what's in REPORT.MAK[scr,sys]. }
@Counter(Section,Within Chapter,TitleEnv HD2,ContentsEnv tc2,
	  Numbered [@#@:.@1],Referenced [@#@:.@1],IncrementedBy Use,Announced)

@Use(Bibliography =  "GENL.BIB[RDG,DBL]")
@Use(Bibliography =  "REPN.BIB[RDG,DBL]")
@Use(Bibliography = "META4.BIB[RDG,DBL]")

@Equate[Fancy = Bold] @Comment{ Later make this better! }
@BEGIN<TitlePage>
@TitleBox{
@MajorHeading[What's in an Analogy?]}

@i{@Value<Date>}

@Heading{Russell Greiner @C[and] Michael R. Genesereth}
@B[Heuristic Programming Project
Computer Science Department
Stanford University]

@BEGIN[TEXT, Indent 0]
@C<Abstract>: @i{
It is quite tempting to view an analogy as a mapping connecting
various parts of the two analogues.
Unfortunately there are several limitations inherent in this approach.
This paper will discuss these deficiencies,
and then present several refinements of this characterization of analogy;
discussing their respective advantages and problems.
This survey culminates with a definition which seems adequate
to handle all common uses of analogy.
The conclusion addresses a few of the issues 
-- both conceptual and at the implementation level --
which must be resolved before this definition can be used.}
@END[TEXT]

@END<TitlePage>

<<here>>	Things to merge in:
@Include(FROM.MRG)

@BEGIN[Equation]
Q: What is the purpose of an analogy?
A: It is a shorthand, to represent a collection of facts 
	about one (or both) analogues.
@END[Equation]
Note these facts may be realized immediately --
i.e. as they may not be noticed until later,
it is often worth keeping around the analogy statement,
as there may be more to milk from it later.@FOOT[
Of course various essentialists and realists
will claim that there is something "real" about an analogy,
on and beyond those connections.
Our decision is not to address such esoteric arguments.
If this means we are seriously shortchanging their concept of "analogy",
we will be glad to use a different name when discussing this same phenomenon.
We'll leave the reader the burden of this
straightforward lexical substitution.]

---

@BEGIN[Equation]
Q: What does it mean to "understand an analogy"?
A: to form (expand, change, ...) a new theory of one analogue
@END[Equation]

MRG claims real task is "understanding an analogy" --
meaning going from that 
@BEGIN[Equation]
ANALOGY(A B <reason>)@Foot[
We still need to define a language for that third parameter.
Should it be English?]
@END[Equation]
to fully instantiated
@BEGIN[Equation]
Analogous( A, B, ?)
@END[Equation]
where that ? includes/uses partial theories of @T[A] and @T[B],
@T[PT@-{A}] and @T[PT@-{B}] respectively.

----

One analogy leads to another (in the sense of "suggests") --
e.g. complete the mapping, or flesh out the current theory.
i.e. Analogous(Th[A], Th[B], α ) => Analogous(Th[A], Th[B], β ) ,
for some different β -- perhaps where β>α, by some partial odering.
[that first Analogous statement might be prelimnary -- i.e. not
of use for any task.

Another possibility is that we go from Th[A] => Th'[A] -- i.e.
use a different formulation of A. (or of B)
Again, it may be standard that @T{Th'[A] @K[GT] Th[A]} (or at least @K[GTE])

----
Q: Why use this CT form?
Note it seems more instantiation than "analogy".

A: 1) It can lead to/suggest other `analogies', (see above)
   2) One might combine more than one analogy to find a new theory.
	[various methods of generating new theories]

-----
Realize the facts true about the 2nd analogue, derived from the
analogy, is just the @T[Range(Map)].
In some sense nothing is gained,
as those facts were presumably known, and used to define the analogy
in the first place.
[Same for CT -- where the facts for that 2nd analogue are just the things
included in the theory, with the appropriate instantiations.]


-----
Arthur's mathematical ability is like Beth's verbal aptitude.

----
Even worse if used ¬Dumb(x)
in leiu of Smart(x)
[hence just matching unary predicate no good]
----

@BEGIN[Equation]
Analogy(A B @G(a) ) @K[IFF] Analogous( PT@-<A> PT@-<B> @G[t(a)] )
@END[Equation]
where @T[PT@-<A>] is a representation for @T[A] --
i.e. @T[A @K<DoubleTurnstile> PT@-<A>];
likewise @T[B @K<DoubleTurnstile> PT@-<B>].
Note this @T[PT@-<A>] is only one of many representations for @T[A].
The @G[t] function remains to be defined,
and will depend heavily not only on the representations, @T[PT@-<x>]s,
but on the nature of the other arguments to @T[Analogous] as well.

Consider telephone...

-----
Make @T[Analogous(A B <ct, m@-{A}, m@-{2}>)],
where @T[ct] is the (common) theory, and @T[m@-{A}], @T[m@-{B}] are mappings.
Note that @T<PT@-{A} @K[EQ] m@-{A}[ct]>, and @T<PT@-{B} @K[EQ] m@-{B}[ct]>,
so these do not need to be included.

---
Consider the use of pipes, filters, ... in Unix operating system!
Could be blocked, or incorrectly attached, or with a bad (ineffective) filter, ...
	append, prepend

@Chapter[Motivation]
@Label<Motivation>

Analogy plays a role in much of the reasoning processing which
people use everyday.
Analogical reasoning is required to understand metaphors 
(as in "she's a packrat") and
similes (like "he eats like a bird"),
as well as many forms of explanations --
when one phenomenon is described in terms of 
(that is, using the model defined by) another,
as seen in the common
"electicity can be understood using the model by water flow" analogy,
or "consider the atom to be a small solar system".
Much of our speech is laced with "extended" meanings,
based on metaphors we had not realized we were using.
We, for example, consider time a precious commodity,
("he didn't have the time to give"),
indicate emotional makeup in terms of spatial (up versus down) position,
("he was feeling down this morning")
and even consider speech to be "laced".

Such evidence supports the view that the ability to generate and comprehend
an analogy is a tremendously useful and powerful tool
-- not only for allowing efficient communication,
but also for increasing our "understanding" of parts of the world.@Foot{
Some recent experiments, (including @Cite[Simon-Repn],)
indicate that expertise is often in the form of storing
(and subsequent fast retrieval of)
some 50-100 thousand "friends"
-- each encoding a particular solved problem,
described in terms of relevant salient features.
Expert level problem solving then involves matching the current problem to the
most apt examplars,
and then applying the associated solution,  @i[mutatis mutandis].}

@SubHeading[Constraints on Definition of Analogy]

Despite the ubiquity of analogy,
there is currently no satisfactory
definition of what an analogy @i{really} is.
The goal of this paper is to present a description of analogy,
one which satisfies several constraints:
It must be compresehensive, 
conform to our (well, my) intuitions,
and explain (i.e. degrade to) other models of analogies.

Comprehensive@*
It must be possible to express 
a wide range of "analogy tasks",
and cover the full breadth of "analogy cases"
using this model of analogy.
There are several types of tasks which seem (intuitively) to require some
type of analogical processing to solve.
(Two examples are "analogy determination" --
going from facts about a pair of analogues to a statement that they are analogous --
and "analogy use" -- which uses the fact that two objects are analogous
to derive some new (i.e. unrealized) fact, usually about one analogue.
A more complete inventory of these will appear in Chapter @Ref[Formal].)
It should be possible to discuss any such task using this formalism.
There are also many ways in which two things can be analogous,
and a different way of expressing each type of analogy.
The formalism should be sufficiently robust to "cover" each of these cases.
(A large collection of examples appears in Chapter @Ref[Examples].)

Conform to Intuitions/Expectations@*
A second constraint on this definition is that the derived analogies
conform to our intuitions, and "feel" consistent.
(Often this means the analogies will lead to valid results 
-- but it is enough for them to lead to plausible, reasonable conclusions.)
That is, knowing that A and B are analogous in some manner should lead
to conjectures about B (based on facts known about A) which make sense.
E.g. knowing that Viral Meningitis (VM) is like Bacterial Meningitis (BM),
and BM is a disease, should lead us to expect that VM is also a disease.
Also, there are some properties we expect of this space of analogies.
For example, 
it should be possible to find some (possibly contrived)
analogy joining any pair of objects.
The non-transitivity of analogies should also hold 
(temporarily viewing analogy as a binary relation of only the pair of analogues.)

Explain other models@*
The third, least important goal is that this definition to "degrade"
into the other standard models of analogy.@Foot{
The canonical example of such a degradation is the way in which
Einsteinian physics degenerates to Newtonian, under simple assumption.}
For example, one common theory holds that an analogy is a structure preserving
mapping of parts of the analogues,
while another claims that two objects are analogous if 
there is a common theory they each satisfy,
in a model theoretic sense.
Each of these descriptions is adequate for dealing with some facet of analogizing;
and we insist on being able to demonstrate how these models are simplified cases
of our more complete description.

@SubHeading[Issues Addressed]
<<Merge these two sections together>>

There are a variety of questions and issues which must be
addressed before this definition can be formulated.
For example, how exactly should an analogy be used?
Are there different types of analogies?  
(If so,) is there a universal ordering of these types?
Are analogies properties of the objects involved, or of their representations --
in particular, what does it mean to observe that different people (societies)
will find (what feels like) different analogies between the same pair of objects.
Etc.

This report will develope these issues, and others, as they arise.
Later, once we have a complete description of what an analogy is,
we can then begin to address the real purpose of any discussion of analogy:
what does it mean to be a @i{good analogy},
and how should one go about writing an effective analogizing program.

@SubHeading[Relevant Questions]
@Label[Qs]

This report will address the follow questions,
towards defining a useful formulation in which to describe meaningful analogies.
@BEGIN[ITEMIZE]
What are the arguments to the @T[Analogous] relation?
It clearly must include the analogues themselves;
must anything else be included?
If so, what?

Does the analogy relation involve a pair of objects,
or their respective representations?

Is it necessary to think of analogy as a mapping?
Is this view sufficient?

How do the requirements/expectations for the @i{analogy determination}
task differ from those for @i{analogy use}?

What is the role of the context when discussing an analogy?

Etc@K[Ellipsis]
@END[ITEMIZE]
@SubHeading[(Meta)Purpose]
<<Here: state this better>>@*
It is important to realize what this paper is NOT:
it does @i{not} provide "how to" information,
which would tell how to build a functional analogizing program, or ...
Instead its purpose is to lay out the groundwork, with which one can discuss
what an analogy is, and thence to define what subset of analogies such a 
program can "cover", ...

@SubHeading[(Meta-)Organization]

Following this overview, Chapter @Ref[Behavior] will
informally describe the type of behavior we expect of an analogy,
using a body of simple scenarios.
Chapter @Ref[Formal] proceeds to
refine this sketch, presenting analogies in a more formal manner.
This chapter will begin to answer the list of questions shown above.
Chapter @Ref[Examples] then lists an inventory of examples,
which will be used as fodder ...

@Chapter["Behavior" of Analogy]
@Label[Behavior]

Enough overhead.  Let's now ask the basic questions
@BEGIN[Equation]
What is an analogy?
... and what is it used for?
@END[Equation]

Informally, the canonical use of an analogy is to
predict/suggest/prove
a new (that is, unrealized) fact about one analogue,
based on a related fact about the other analogue.
The (metaphysically based) argument is that
if two things are similar in some respects,
we may suspect that they will be similar in other ways as well.

But how is an analogy deduced?  
And what does it mean to then use this analogy?
Our goal is to @i{formally} express what is @i{really} going on here.
This requires understanding
the type of (behavioral) characteristics one would expect of an analogy.
It introduces questions like
what an analogy can be used for,
and what rules of inference are needed to ...

First, to instantiate some of the ideas, we will work through a few
simple examples, to show the type of behavior we expect of an analogy.
Then, in Chapter @Ref[Formal], we will break down this process,
to make each step more formal.
...
<<what goes here?>>
@Section[Informal Scenarios]
@Label[Informal]

This section will build up the notion of the use of an analogy 
-- starting with some silly sounding conjectures,
and working towards an effective description.

We'll begin with a simple example:
@BEGIN[Equation]
"Bacterial-Meningitis is analogous to Viral-Meningitis."
@END[Equation]

Now what can we do?
Well, knowing that Bacterial-Meningitis is a disease,
we probably would like to conclude that Viral-Meningitis is a disease.

It would be silly to conjecture that
@BEGIN[Equation]
@TAG<An1>
@K[Forall] A,B. Analogous(A B) @K[Implies] Disease(A).
@END[Equation]

This is obviously false:
From @T[Analogous(ElectricSystem WaterFlow)],
we should @B[NOT] conclude that @T[Disease(WaterFlow)].
(Note also that this uses a binary @T[Analogous] relation.
We will soon see that this is problematic.)

So maybe we want something like
@BEGIN[Equation]
@TAG<An2>
@K[Forall] A,B,F. [Analogous(A B) @K[And] F(A)] @K[Implies] F(B).
@END[Equation]
[Of course these @T[F] predicate symbols may be arbitrarily complex 
-- perhaps lambda expressions which ...
Also, they have to be sufficiently general to encompass both @T[A] and @T[B], etc.]

Hence, given @T[Analogous(Viral-Meningitis Bacterial-Meningitis)] and
@T[Disease(Bacterial-Meningitis)], we correctly conclude
@T[Disease(Viral-Meningitis)].

This @Ref{An2} is still problematic:
Consider that fact
@T[CausedBy(Bacterial-Meninigitis Bacteria)].
Clearly we do not want
@T[CausedBy(Viral-Menigitis Bacteria)], as, by definition,
viral menigitis is caused by a Virus.

That's the first nail.  
There still might be some solution, by claiming that,
inherent to the analogues @T[A] and @T[B] are a set of "transferable facts".

@NoIndent()Perhaps it is due to but one of the analogues, i.e.,
@BEGIN[Equation]
@TAG<An3>
@K[Forall] A,B,F. @↑[Analogous(A B) @K[And] F(A) @K[And] PredicatedOKedBy(A F)]
@\@K[Implies] F(B).
@END[Equation]

@NoIndent()This too fails.  Consider the@Foot[
This "the" is inappropriate -- we'll later see that "a" should have
been used.]
"a spoon is like a fork" analogy,
Hence we would need
@BEGIN[Equation]
PredicatedOKedBy(Spoon SilverWare)			
@END[Equation]
to see that a fork is also a piece of silverware -- hence
@BEGIN[Equation]
[Analogous(Spoon Fork) @↑@K[And] SilverWare(Spoon)
@\@K[And] PredicatedOKedBy(Spoon SilverWare)]
  @K[Implies] SilverWare(Fork).
@END[Equation]
	
But now we want to assert that "a spoon is like a shovel",
in that either can be used for scooping.
Given
@BEGIN[Equation]
PredicatedOKedBy(Spoon SilverWare)
@END[Equation]
we could, using @Ref[An3] above, deduce that 
@BEGIN[Equation]
SilverWare(Shovel)
@END[Equation]
-- WRONG!

Reciprocally we can show that
@BEGIN[Equation]
@TAG<An4>
@K[Forall] A,B,F. @↑[Analogous(A B) @K[And] F(A) @K[And] PredicatedOKedBy(B F)]
@\@K[Implies] F(B).
@END[Equation]
(i.e. where the other analogue gets to confirm the predicate)
does not work.

It is still possible that, somehow, both analogues together decide whether
some property should be transfered over -- i.e. that
@T[PredicatedOKedBy] is a tertiary relation, of @T[A], @T[B] and @T[F].
Hence
@BEGIN[Equation]
@TAG<An5>
@K[Forall] A,B,F. @↑[Analogous(A B) @K[And] F(A) @K[And] PredicatedOKedBy(A B F)]
@\@K[Implies] F(B).
@END[Equation]
@SubHeading[Something else is needed]
@Label[MoreThan2]

While better, this too turns out to be deficient.
Intuitively, the problem arises because there is more to an analogy
than just a pair of analogues:
This becomes evident in cases when more than one analogy
seems to connect the same pair of analogues;
and is problematic when each analogy leads to a different
(and incompatible) set of conclusions.
We will show below a situation where one predicate, @T[F@-{1}], makes sense in
the case of one analogy,
while a different @T[F@-{2}] seems apt in another;
where these two predicates are incompatible,
in the sense that they cannot both hold at once -- i.e.
@BEGIN[Equation]
F@-{1}(B) @K[And] F@-{2}(B) @K[And] (other facts re: B) @K[Implies] False.
@END[Equation]

@NoIndent()Towards a contradiction,
consider a world in which
@BEGIN[Equation]
@K[ForAll] x. Smart(x) @K[Implies] @K[Not] Strong(x),
@END[Equation]
and in which we have established that
@BEGIN[Equation]
@TAG<AnAB>
Analogous(Arthur Beth),
@END[Equation]
and
@BEGIN[Equation]
Strong(Arthur).
@END[Equation]
The question is whether
@BEGIN[Equation]
? Strong(Beth) ?
@END[Equation]

What @Ref[AnAB] @i{really} means is now important.
If it was meant to encode that
@BEGIN[Equation]
@TAG<AnAB1>
"Arthur is physically like Beth",
@END[Equation]
then we would expect that @T[Strong(Beth)] would hold.
However, what if it really meant that
@BEGIN[Equation]
@TAG<AnAB2>
"Arthur's brawn resembles Beth's brain"?
@END[Equation]
Here, while we are still comparing Arthur to Beth,
we would expect to deduce that
Arthur's strength would correspond to Beth's IQ,
(and not to her strength, as in the first case,)
which would imply that
@BEGIN[Equation]
Smart(Beth),
@END[Equation]
and therefore
@BEGIN[Equation]
@K[Not]Strong(Beth).
@END[Equation]

We now have quite a dilemma.
It seems reasonable for @T{(Analogous Arthur Beth)} to lead to
@T{Strong(Beth)} in one situation,
but to @T{@K[Not]Strong(Beth)} in another.
This apparent contradiction is easy to solve, if the @T[Analogous] relation
took one (or more) additional arguments, which somehow encoded which of
the senses @Ref[AnAB1] or @Ref[AnAB2] was meant.
Then, seeing that
@T{(Analogous Arthur Beth "@Ref[AnAB1]")} leads to
@T{Strong(Beth)} while
@T{(Analogous Arthur Beth "@Ref[AnAB2]")} does not 
would cause us no discomfort.

@SubHeading[More Examples]

We will discuss the ramifications of this point later.
First, it is worth pointing out that this contrived "Arthur and Beth" example
is not unique --
there are many situations where we would want to reach quite different conclusions,
based on a statement of analogy which relates a pair of analogues.

Consider the proportional analogy question:
What is the best @T{?} for
@BEGIN[Equation]
Washington : 1 :: Lincoln : ?
@END[Equation]
<<Here: cite whoever first mentioned this>>
If we regard Washington and Lincoln as presidents, and observe that
Washington was first president, the obvious answer is @T[?=9],
as Lincoln was the ninth president.

We might, however, think of Washington in terms of his relation to
a US currency bill.
As Washington's portrait appears on a 1 dollar bill,
and Lincoln appears on 5 dollar bills,
one could argue that @T[?=5].

So which is the correct answer, @T[?=9] or @T[?=5]?
While both are clearly plausible, they cannot both be true.
For our system to be consistent,
we cannot have both following from
@BEGIN[Equation]
Analogous(Washington Lincoln)?
@END[Equation]
The point here is that we do want to be able to reach either conclusion,
(but only one,)
each under its own set of circumstances.

Another example is from @Cite[Hof81]:
@BEGIN[Equation]
Who is the first lady of England?
@END[Equation]
This can be reworded to
@i{find the way in which "first lady" related to the (implicit)
USA, and use this to find the best individual who relates in that same
manner to England}.
Depending on the individual queried, the response might range from
"Mr Thatcher" to "Lady Diane", etc., depending on ...
<<here>>

@SubHeading[@i{Post Mortem} on Binary Analogous]

This evidence forces us to realize there must be something else to an analogy,
besides just the analogues themselves.
This whole @T[PredicateOKedBy] mechanism (hack?)
was merely a simple (and temporary) way of encoding the fact that 
different types of properties should be mapped over in different situations.
We can now abandon this contrivance,
in favor of a single, comprehensive @T[Analogous] relation.
(This is why we did not consider the
"logically adequate" solution of enhancing that @T[PredicatedOKedBy] relation,
giving it (and not @T[Analogous]) an additional argument
which refers to the current situation.)

This new improved @T[Analogous] relation does "feel" more correct.
With it we can state that there are different analogies between Arthur and Beth,
and different conclusions should follow these different analogies.
The previous formalism,
as given in equation @Ref<An5>,
seemed to imply there could one analogy between Arthur and Beth.
There is still much more work needed -- to determine how to encode
this "contextual" (and other?) information.
We will return to this point later, in Chapters @Ref[Map-Gen] through
@Ref[Answer].
@Section[@i{Depth} of an Analogy]
@Label[Depth]

All of the above analogies feel quite "trivial",
in the sense that they map over rather superficial features
from one analogue to the other.
Before we plunge into the more theoretical work,
it is worth presenting some other analogies,
which exhibit "deeper" analogical connections.
(We will later formalize this sense of "depth" of an analogy 
-- see Chapter @Ref[?].)

Consider the standard teaching technique of using one "system" to explain another.
The canonical example is learning about electrical circuits,
based on the observation that they behave just like water flow,
with masses of electrons (holes) serving the role of water,
wires being like pipes, resistors like thin pipes, etc.
Similarly the terminology of "message passing", in the @i[Actor]-like systems,
is borrowed directly from our day to day communication processes;
and is, in turn, a convenient formalism for describing the networks present
in our internal endocrine system.
Whole fields are actually based on such connections --
consider cognitive science, which, basically, derives from the claim that
people can be viewed as information processors,
in much the same manner used for computers.
@Cite[Lakoff] expands this claim
by noting that a vast part of our usual "non-metaphoric" speech is,
in fact, based on "hidden" metaphors.
Many of our terms for emotions are based on the "up vs down" linear ordering --
<<here more examples, less metaphoric>>
; and even the metaphors used show an incredible systematicity --
as in "he was up in the clouds", "she was down in the dumps", ...

In all of these cases we find that the "underlying mechanism" for one
phenomena has been borrowed to explain another.
In slightly more formal terms, we have two models which each satisfy the
same partial theory, differing (within the given theory) by instantiation
of names alone.
That is, both electrical circuit and water flow networks satisfy a single
general theory of circuits, conduits and material flow.
<<here - what more should be said?>>

This leads to a different model of analogy:
that A and B are analogous if there is some (partial) theory which they both
satisfy, in a model theoretic sense.
We will discuss the merits and inadequacies of this view later,
in Chapter @Ref[Common-Gen].

@Chapter[Formal Description of Analogy]
@Label[Formal]

The prior chapter demonstrated the types of "analogizing inferences"
we would like to make.
With this background, we will now attempt to define, more formally,
what is "going on" during an analogizing situation.

The basic idea is to use facts about A and B (both individually and together)
to first derive a proposition of the form
@T[Analogous(A B @G(a))]@Foot[
This "@G(a)" is to encode the additional arguments which we saw above
had to be included.
If more than one such parameter is needed, think of @G(a) as encoding that
n-tuple.
See Chapter @Ref<?>.
Also, we have not committed ourselves to the actual form of the first two
arguments -- i.e. whether @T[A] and @T[B] themselves will be used,
or some other pointer to these objects.
See Section @Ref<TorO>.]
and later to use this assertion, possibly augmented with other facts,
to conjecture (or deduce) some new fact about A and B,
e.g. @T[f(A B)].
Usually, as in the examples above, this new fact pertains to one analogue
(i.e. is of the form @T[f'(B)],)
and is based only on some facts about @T[A] -- @T[g'(A)].
Schematically,

@BEGIN[Equation]
***Analogy Determination***
	F@-{1}(A)
	F@-{2}(B)
	F@-{3}(A B)
	...
	------------------
	Analogous(A B @G(a))
@END[Equation]

@BEGIN[Equation]
***Analogy Use - General***
	Analogous(A B @G(a))
	g(A B)
	------------------
	f(A B)
@END[Equation]

@BEGIN[Equation]
***Analogy Use - Standard***
	Analogous(A B @G(a))
	f'(A)
	------------------
	f''(B)

@END[Equation]

Note first that many descriptions of analogy ignore this intermediate 
"@T[Analogous(A B @G(a))]" proposition.  
That is, the analogy is viewed as starting with a collection of facts 
known of @T[A] and @T[B]
(possibly augmented with a description of @T[A]'s relation to @T[B]),
and using these to conclude/conjecture some new fact about one of the analogues.
This is what happened in the informal cases above.

Note second that, while this description may be adequate, and sufficient,
it is general enough to be useless.
In fact, it might appear that all an analogy can do is repeat back to you
facts you already must have known --
i.e. allowing you to
(circuitously re-)derive from @T[(Analogous A B @G(a))] 
the very facts used to deduce this proposition.
How can one break this cycle;
is there some way to derive a new fact (or conjecture) from the
@T[Analogous] proposition?

In this paper we propose a way of "expanding" an analogy,
to permit other conclusions to be formed.
This involves inserting a new @T[Analogy Expansion] step,
between the @T[Analogy Determination] starting step and
the @T[Analogy Use] conclusion.
@T[Analogy Expansion] is the process of going from the known
@T[(Analogue A B @G(a))] to
a conjectured @T[(Analogue A B @G(b))],
where, under some useful partial ordering @K[AsymptGTE],
@BEGIN[Equation]
@G(a) @K[AsymptGTE] @G(b).
@END[Equation]
It is from the @T[Analogous] clause which involves this new @G(b) that
new deductions about @T[B] are derived.

[Here we can discuss cases:
In one situation this @K[AsymptGTE] relation "preserves validity" --
that it only somehow "closes off" a given analogy, and leads only
to valid conclusions about @T[B].
We also permit ourselves the option of forming "riskier" extensions to @G[a], 
which, in turn, lead to statements which are "reasonable" to make about
@T[B], as opposed to being guaranteed correct.
]
<<<here: merge this in>>>
@SubHeading[Goals of Analogizing]

Having established this notation,
we can begin to consider a useful description of meaningful analogies.
The two goals are
@BEGIN[Enumerate]
to find the set of conditions needed to deduce that @T[A] and @T[B]
are analogous,
(and possibly, in what way), and

to consider a description of analogy which permits "reasonable"@Foot[
This "reasonable" criteria is of course subjective.
This is just one argument in favor of having multiple types of analogies.]
new conjectures to be raised.
@END[Enumerate]

There are, of course, a host of other, secondary objectives which might
be considered.
For example, we are not concerned with familial analogies -- 
i.e. relations which join more than just two analogues, as in
the Wittgenstein-ian "game" notions,
or the common characteristics of the spines of all vertebrates.
Another situation deals with proportional analogies.@Foot{
There are, of course, tricks to convert the proportional analogy,
@i[A:B :: C:D], into a similarity analogy, whose analogues are the terms
@i[REL(A B)] and @i[REL(C D)],
where
@i[REL(@g<a> @g<b>)] denotes a relation which holds between
@g<a> and @g<b>.
We can now talk about this pair of relations, as we could any other object.
(Bravo for second order languages.)}
While this formalism might very well scale up to handle these peripheral cases,
(which would clearly be a desirable feature,)
such points will not be (further) addressed in this paper.

Given this description, we can now more formally address
the questions mentioned way back in Section @Ref[Qs].
This report will proceed to discuss these various questions, in turn.
@Section[Arguments to "Analogous"]

What must go into this analogy relation?  
Certainly a pair of things corresponding to the two analogues.
(We'll later discuss what this "correspondence" is.)
We saw above that something else was needed;
that @T[Analogous] was not a two place predicate.

Realize that this was not a "straw man" argument.
We do indeed say that 
"Viral meningitis is like Bacterial meningitis",
or "Electrical system is like water flow";
which sounds a lot like
@BEGIN[Equation]
Analogous(ViralMeningitis BacterialMenigitis)
Analogous(ElectricalSystem WaterFlow).
@END[Equation]

Of course these propositions do indeed "encode" the above statements.
Our goal, however, is to produce @i{meaningful} forms,
which can then be effectively utilized.
Unfortunately this simple binary relation is not sufficient
to consistently draw the type of conclusions we would want.

The proof presented above stems from the realization that there are times
when a pair of analogues can be analogous in more than one way.
(See Section @Ref[MoreThan2].)
Before mentioning some other arguments why 
@T[Analogous] must have additional parameters,
we will address some related issues and possible counter-arguments.
@SubHeading[Just Linguistic Problem?]
@Label[IssuesWRT2]

First, perhaps this whole issue, as stated, is a purely linguistic confusion.
That is, perhaps we should have been comparing 
@T[Arthur'sPhysique] to @T[Beth'sPhysique] in the first case,
and to @T[Beth'sMind] in the second.
Then the whole problem would be 
how to go from the English statement to the actual statement of analogy --
@BEGIN[Equation]
Analogous(Arthur'sPhysique Beth'sPhysique) and
Analogous(Arthur'sPhysique Beth'sMind),
@END[Equation]
respectively.

This argument can be countered by considering the analogy that 
@BEGIN[Equation]
"Arthur is as heavy as Beth is tall".  
@END[Equation]
Is the correct analogy statement here 
@BEGIN[Equation]
Analogous(Arthur'sPhysique-Weight Beth'sPhysique-Height),
@END[Equation]
to distinguish this analogy from the one
which compares their respective weights, which would be stated as
@BEGIN[Equation]
Analogous(Arthur'sPhysique-Weight Beth'sPhysique-Weight).
@END[Equation]
And if you permit this expansion, we can then get increasingly more refined,
when we want to compare
@T[Arthur'sPhysique-Weight, in grams, when he stands on Jupiter,]
with @T[Beth'sPhysique-Height, in centimeters] -- if they turn out to be equal.
Another problem is that we still have not addressed what the basis of comparison
is to be, even given the things to be compared.
Hence, while the match might be in terms of similar value,
it also might be that these quantaties have the same digits,
in standard base ten expansion, when rounded to the nearest unit, etc.
Where does it end?

@SubHeading[Why So Seductive?]

A second issue is why was it this binary @T[Analogous(A B)] form so seductive?
That is, why did it seem sufficient?
To answer this, realize that, in general,
@BEGIN[Enumerate]
there is a single prefered perspective in which to view the
analogues, which well forces the analogy itself.

in the rare case when there are more than one way to consider @T[A] and @T[B],
usually one of pair of these perspectives makes any sense 
(the others being seen as funny.)  Again, no problem.

in many of the remaining cases, when @T[A@-{1}] and @T[A@-{2}] 
(each a perspective of @T[A])
match to @T[B], these matchings are independent,
which means these "mappings" can be merged.

even of the remaining problematic situations,
where @T[A] and @T[B] can correspond in different and INCOMPATIBLE ways,
there is usually some specific context which dictates which perspective
should be considered -- and again, the other perspectives seem silly.
@END[Enumerate]
It is only the final case, when there is no strong context, or where this
context does NOT further disambiguate, that we have problems.
(Which is why it was relatively difficult for the authors to find any reasonable
sounding, convincing example.)

@SubHeading[Other Failings of Binary Form]

Let's now consider some other failings of this binary form of @T{Analogous}.
It would be too tempting to see this relation as transitive --
after all, if Arthur is like Beth, and Beth is like Charles,
then it would seem reasonable to expect Arthur to be like Charles.
This does hold, when the reasons for their pairwise similarity are the same
(e.g. if it is in terms only of height).
Of course if Arthur is like Beth mentally, and Beth resembles Charles physically,
there is no reason to expect Arthur to share either mental or physical
similarities with Charles.

Another confirming argument derives from analogizing tasks of the
"What is like @i{x}?" flavor:
Realize that anything is "like" (any) @i{x} --
we need some (not necessarily explicit) guiding/pruning constraints
for this problem to make sense.
This may be in form of another analogy -- leading to the famous
?Miller? analogy tests, which use the proportional form
@BEGIN[Equation]
A:B :: C:?
@END[Equation]

Another related (and unfortunately, as weak) argument is based 
on the observation that
people find it rather easy to compare analogies. 
(The above case, of determining which of a collection of objects 
best corresponds to some starting analogue is but one example of this.)
This more general sitation could also include cases like
"Arthur is more like a door than a window.".
This implies that @T[Analogous(A B)] should be a term,
which somehow indicates at least the strength of this connection --
that is, provides a handle with which to compare a pair of analogies.

Finally, realize that one can explain an analogy --
and that people, intuitively, consider such an explanation as
a part of the analogy itself.
(Consider what usually happens when someone explains an analogy to some one
who didn't "get it" at first:
The standard response is of the form "Oh I see there are analogous by
that constraint.  I was only thinking of <A> as ..." --
implying that the analogy now makes sense, giving this additional information;
and explaining what had been missing from the pre-understanding individual.)

<<here - any additional args?>>

@Section[Theory or Object?]
@Label[TorO]

Before we can answer the question of what the additional arguments are,
it is necessary to resolve the nature of the first two argument, @i{viz.},
@BEGIN[Equation]
Is analogy a property of the objects, or of their representation?
@END[Equation]

Before explaining why this question is important, and in particular,
why it has to be resolved before we can consider the nature of
@T[Analogous]'s other arguments,
we have to explicate what this question means.
Of course the @T[Analogous] proposition itself
will use some symbols, which someone correspond to the analogues.
The question is, how direct is that correspondence?
Do these symbols each refer to an object (e.g. the real world object named Beth,)
or to descriptions of those objects (e.g. 
@T[ { (Beth @K[MemberOf] People) (Student Beth) ... (Height Beth Tall) } ] ).
In the later case, does it matter what particular formalism is used --
not just whether the predicate calculus is used, versus a unit/slot/value frame
system,
but also aspects which deal with what exactly is represented (explicitly?),
whether the description is "dynamic" or "static", etc.

Whatever the additional arguments are, they clearly must consider the
"value" of the first two parameters.
For example, if we think of analogy as a mapping,
we have to decide what is mapped onto what.
If it is parts of one analogue onto parts of the other,
There are many ways of "partitioning" an object, and each such
decomposition may lead to a different analogy.
In this case the analogy (read mapping) holds only if the particular
representation ...
<<here>>

That is, does the "Arthur is mentally like Beth" analogy
if I don't realize that both
Arthur and Beth are lawyers, 
s Arthur's analogical connection to Beth depend on the
<<Here - tell why this is relevant question to ask:>>
For example, does it make sense to claim that different people,
who know different things...

Now we can ask whether we should claim it is the same analogy which
joins A to B, if we are dealing with different representation.
[E.g. circles in polar vs in rectagular co-ordinates.
or as the coordinate system shifts, (e.g. to place the center at the origin),]

If the connection was a mapping, for example, of what to what?
Does the nature of the connection depend on 

The answer is both yes and no.
First, abstractly, we feel that analogy is (or should be) a "semantic relation",
which deals with a pair of objects, as opposed to a pair of descriptions.
That is, whether rubber bands and the American economy are analogous
may depend on whether the economy is constantly springing
back towards a stable equilibrium state,
but should be independent of whether we happen to know
(and happen to have encoded)
this fact.

It is another issue altogether to decide how difficult it is to
@i{realize} a given analogy.
Here the representation of the analogues is obviously quite important:
We would have a harder (if not impossible) time 
discovering this"rubber-band/American-economy" analogy
if we did not know this (assumedly true) fact,
while this analogy would be trivial to deduce
if our representation happens to mention this "resiliency" property explicitly.
That is, while some representations will do a better job of explicating
the analogy than others, the analogy is true in any event:
the difficulty of this determination is irrelevant
to the veracity of the analogy.

Given our total knowledge of integers, this was not much of a limitation --
as we could, (in theory if not in practice) store all relevant facts about
the integers.
We do not have this liberty when dealing with real world objects.
Here the given description of the object may not
explicate (or worse, not even include) the features
which should be in correspondence, for this analogy.
This problem points to the necessity of reformulation for
any sophisticated analogizing program -- that is, the program must be
able to find a different representation for (one or both of) the analogues;
in which the desired commonality is expressed.}

This leads to a (the?) major difficulty in analogy determination:
how to find the correct -- i.e. most useful -- representation for the analogues.
We will touch on this issue, called "reformulation", in the next section.
Later all of Section @Ref[Reform] will be devoted
to this important issue.

<<here>>
@SubHeading[But...]
@Label[NeedsRepn]

We mentioned above the difficulty of deduction,
noting in particular how this is tied to the particular formulation used to
represent the analogues.
<<here - mention Analogy relation.>>

Now for the other side of the answer:
We unfortunately do not have "access" to the objects in consideration themselves,
but only certain abstractions of these things.
Hence the best our @T[Analogous] relation 
(as distinct from the abstract analogy relation@Foot<
From now on we will use the capitalized form @T[ANALOGY]
when referring to the abstract relation,
leaving the lower case @T[analogy] to refer to cases when the analogues,
in some particular representaton, satisfy the @T[Analogous] relation.>
can do is consider these particular representations of the analogues.
Hence the other arguments to the @T[Analogous] relation,
which define the analogy,
will depend on the particular description of the analogues.

That is, imagine the only fact we know about Arthur is that
@BEGIN[Equation]
@Tag<ThA1>
Th[Arthur] @K[Eq] @K[LeftBrace] Strength(Arthur Great) @K[RightBrace],
@END[Equation]
and that we knew only that
@BEGIN[Equation]
@Tag<ThB1>
Th[Beth] @K[Eq] @K[LeftBrace] IQ(Beth Great) @K[RightBrace].
@END[Equation]
(The notation @T<Th[x]> refers to the theory of @T[x] 
-- i.e. what facts are known to be true of @T[x].)
The only reasonable statement of analogy@Foot<
note lower case>
is 
@BEGIN[Equation]
@Tag<AnlgsAB1>
Analogous(Th[Arthur] Th[Beth] "Strength(Arthur)@K[ApproxEq]IQ(Beth)").
@END[Equation]
(It remains to see how we will encode the "scare quoted" phrase above.
That discussion occupies from Chapter ? through Chapter ?'.)

Imagine now that we knew, instead, that
@BEGIN[Equation]
@Tag<ThA2>
Th[Arthur] @K[Eq] @K[LeftBrace] IQ(Arthur Great) @K[RightBrace],
@END[Equation]
where @T[Beth] was unchanged.
(Note it may still be true that @T[Strength(Arthur Great)];
the point here is that this fact is no longer represented.)
Under this circumstance it is reasonable to state that
@BEGIN[Equation]
@Tag<AnlgsAB-2>
Analogous(Th[Arthur] Th[Beth] "IQ(Arthur)@K[ApproxEq]IQ(Beth)").
@END[Equation]
That is, we have now found a different analogy connecting these same analogues.

@SubHeading[Some additional comments:]
Of course both ANALOGIES connected Arthur to Beth all along;
they were, however, found @T[Analogous] only when their theories were
sufficiently inclusive.

The way the facts are encoded plays an important role when determining analogies.
Imagine we
replaced @Ref<ThA1> and @Ref<ThB1> with
@BEGIN[Equation]
@Tag<ThA3>
Strong(Arthur),
@END[Equation]
and
@BEGIN[Equation]
@Tag<ThB3>
Smart(Beth).
@END[Equation]
The only analogy we might find here will relate @T[Strong] to @T[Smart];
while it will be isomorphic to @Ref<AnlgsAB1>, it is NOT the same analogy.
This makes sense --
while that other connection "feels" pretty reasonable,
this other one is clearly not as obvious, and feels rather contrived.

Returning to the point above, we might say that while the analogy found 
based on @Ref<ThA1> and @Ref<ThB1> is different from the one found
based on @Ref<ThA3> and @Ref<ThB3>,
the corresponding ANALOGIES are the same.

We can state this a bit more formally with the aid of a new predicate,
@BEGIN[Equation]
ANALOGY(A B Reason)
@END[Equation]
where @T[A] and @T[B] are objects, as opposed to theories.
Then we want to say that
@BEGIN[Equation]
ANALOGY(A B Reason) @K[SCurve] Analogous( Th[A] Th[B] ...)
@END[Equation]
where the obvious constraints hold -- @i{viz}.,
@T{A @K[DoubleTurnstile] Th[A]},
@T{B @K[DoubleTurnstile] Th[B]},
and the 
@T[Reason] terms of the @T[ANALOGY] proposition
must somehow correspond to the
@T[...] part of the @T[Analogous] statement.
(Of course that depends on those arguments.)

We can interpret this "@K[SCurve]" as "leads to",
and note that it might be one-to-many:
i.e. a single @T[ANALOGY] statement might lead to many different
@T[Analogous] forms.
First, there are many different "abstractions", 
@T[Th(A)] and @T[Th(B)],
one can associate with these @T[A] and @T[B] analogues,
and each of these distinct formulations can lead to a different @T[Analogous]
statement.
Second, even given a particular pair of abstractions,
there may be alternate @T[...] which conform to @T[Reason] --
e.g. <<here - give an example>>

While everything above has focussed on analogy determination,
realize that the representation plays an important role is analogy use as
well.
That is, the new facts we might deduce/conjecture based on an analogy
will heavily depend on the particular facts noted,
and on the particularities of the way these facts are encoded.

@Section[??? where does this go? Reformulation Issues]
-- what about stuff on page
@Label[Reform]

We can define
@BEGIN[Equation]
Reform(T@-{1} T@-{2} X) @K[IFF] [X @K[DoubleTurnstile] T@-{1} @K[And] X @K[DoubleTurnstile] T@-{2}]
@END[Equation]
i.e. if the theories @T[T@-{1}] and @T[T@-{2}] each represent the model @T[X].

Note this definition seems a bit too generous.  
Recall the various theories of Arthur,
@Ref<ThA2> and @Ref<ThA1>, discussed on @PageRef[NeedsRepn].
There the two formulations are independent -- in the sense that
there is no way one could derive one collection of facts from the
other.

Three classes:
@BEGIN[Itemize]
@Tag<ILoss>
Information Loss -- i.e. filtering out some of the facts.

@Tag<IPreserve>
Information Preserving -- e.g. change from rectangular to polar coordinates

@Tag<IGain>
Information Gain -- this requires additional sensory input.
@END[Itemize]

Few people will argue that @Ref<IPreserve> qualifies as reformulation;
@Ref<ILoss> feels like a degenerately easy special case;
and @Ref<IGain> seems like a different phenomena all together.
@Chapter[Simple Analogy Examples]
@Label[Examples]

@COMMENT{ Everything from this Page 25 upto Page 36 was copied from
	ANLGY.MSS[rdg,dbl] (pages 12-23) on 24-Nov-82 }
Our next goal is to determine
@BEGIN[Equation]
What are the additional arguments to the @T[Analogous] relation,
beyond the analogues themselves?
@END[Equation]
Before we can address this question,
we will need an inventory of analogies to deal with.
This chapter presents such a list.

Each entry is an "analogy comprehension task" --
a problem statement which implies some connection between the pair of analogues.
We will consider an analogizing program adequate only if it is able to
"understand" all of these
-- that is, if it is able to use the connection
to conjecture some new assertions about one or both of the analogues.

Note this means that the analogy must first be generated, and then used.
Hence this involves both types of analogy types, mentioned above.

The list below covers a wide spectrum of cases 
-- ranging from very precise and formal,
based on "deep underlying similarities",
to relatively shallow and informal similarities.
These will be coarsely divided into two broad@Foot{and overlaping}
classes of examples -- labelled formal versus informal.
(Note @Ref[Dims] presents a cut of the dimensions which could be
used to specify an analogy case, within this format.)
Each case will be followed with a quick and informal statement of what this
analogy @i{really} means.

Note that each of these problems can be formulated in the format 
@BEGIN[Equation]
"A is like B, within constraint @G[a]."
@END[Equation]
In each case both analogues have already been named, 
and there is some indication of the inter-connecting analogy.
Furthermore, we can assume the "hearer" is familiar with
(@i{i.e.}, knows lots of facts about)
at least one of the analogues.
The canonical task, now, is finding some new properties of the other analogue,
based on that 
"triggering"
analogy description.

@Section[Case I - Formal]
@Tag[FormalExs]

Consider the task of deducing some new fact about
@B[INTEGERS],
@Foot{
This general structure, @B[INTEGERS],
consists of both the obvious universe of elements,
and of the wide range of relations pertanent to these members --
including the functions @K[PlusSign], @K[TIMES], @i[Successor], ...
relations like @i[>] and @i[Divides], and constants like @i[0] and @i[1].}
based on knowing some fact about @B[RATIONALS].@Foot{
... which similarly includes several of its operations and constants
as well as universe of members.}
This requires two steps --
first determining how @B[INTEGERS] was analogous @B[RATIONALS],
and then using this analogy.

Example questions include:
@BEGIN[ITEMIZE]
What is true about < @B[Z],@K[PlusSign],@i{0} >?@*
@w(    )A: It is a group.

Is @K[PlusSign] associative, over @B[Z]?@*
@w(    )A: Yes.

How is @B[INTEGERS] like @B[RATIONALS]?@*
@w(    )A: Each embeds a group structure.
@END[ITEMIZE]

@SubHeading[Totally Specified Analogues, Precise Analogy]

Suppose we are told that@*
@i{The integers, under addition, with the zero element 0, are like
the rationals, under multiplication, with the zero element 1,
(in that each structure is an instance of a group)}
-- symbolically
@BEGIN[Equation]
@TAG[ZQ1]
< @B[Z],@K[PlusSign],@i{0} > @K{BarTilde} < @B[Q],@K[Times],@i[1] >
@END[Equation]

@COMMENT[That @B(Z) should be Integers - Z with a line thru it;
and @B(Q) should be Rationals - Q with a line thru it.]

Before asking what this means, consider what we can do with this information.
For example, if we know some fact about @B[Z] and @K[PlusSign], for example, that
the @K{PlusSign} operation is associative, we can then conjecture that @K[TIMES]
might be associative over @B[Q].  (... and, lo and behold, it is!)

(Now,) what does @Ref[ZQ1] mean? 
As an instantiation of a group, each structure satisfies the following
axioms:@FOOT[
We could, in fact, even state that each structure is an infinite,
(of cardinality @g[w],) Abelian group 
-- but that digression is not important here.]

@BEGIN[Equation]
Set( Univ(G) )

Zero(G) @K[MemberOf] Univ(G)

BinaryOperator( Oper(G) )

Associative( Oper(G) )
  (i.e., @K[ForAll] x,y,z @K[MemberOf] Univ(G).
             [(x Oper(G) y) Oper(G) z] = [x Oper(G) (y Oper(G) z)]]

Identity( Zero(G), Oper(G), Univ(G) )
  (i.e. @K[ForAll] x. x @K[MemberOf] Univ(G) => (x Oper(G) Zero(G) ) = x. )
@END[Equation]
@NOINDENT()where
@i[Univ(x)], @i[Oper(x)] and @i[Zero(x)] are unary (skolem) functions
mapping a structure into its parts;
which here extracts the first, second and third elements of a triplet,
respectively.

This case is, of course, a gross simplification of any real world situation,
in (at least) three ways, all of which will be addressed below.
First, notice that we were already given both structures,
and thereby told, explicitly, both which aspects of @B(Z) to consider,
and how to consider these facets.
In addition, we have been explicitly given the theory
which both of these structures satisfy -- group theory.
(That is what makes that (supposedly analogical) inference above so trivial
-- the associativity of the operation over the universe is automatically true
in any group.  Yawn.)

@SubHeading[Partially Specified Analogues, Precise Analogy]

Now imagine being told only that the general structure, @b[INTEGERS],
is similar to the structure @B[RATIONALS],
in that each is an instance of a group.
Here any analogy task first would require the hearer to
specify which @b[INTEGERS] (resp., @b[RATIONALS],) things correspond to the 
group things -- universe, operation and zero element.
Hence the correspondences could be
@BEGIN[Equation]
< @B[Z],@K[PlusSign],@i[0] > @K[BarTilde] < @B[Q],@K[Times],@i[1] >
@END[Equation]
(as it was before,) or
@BEGIN[Equation]
< @B[Z],@K[PlusSign],@i[0] > @K[BarTilde] < @B[Q],@K[PlusSign],@i[0] >,
@END[Equation]
or even
@BEGIN[Equation]
< @B[Z]@-{7},@K[Times]@-{7},@i[1@-{7}] > @K[BarTilde] < @B[Q],@K[PlusSign],@i[0] >,
@END[Equation]
(the above notation refers to the integers mod 7, under multiplication).

@SubHeading[Partially Specified Analogues, No Analogy Given]

Now suppose we were only told that these structures are similar, but not how --
@i{i.e.}, we were not given that each should be consider as a group.
Perhaps we should consider both as rings, or monoids, or lattices, or ...  
There are arbitrarily many connections one might make -- both those deriving
from some mathematical structure, and otherwise.
(Recall the famous "consecutive subway stops in NYC" example).

@Section[Case II - Informal]
@Tag[InformalExs]

In all of these cases, we were dealing with artifical objects;
and in the first two cases, the desired commonality was equally man-made.
The third loosening occurs when the analogues refer to natural,
rather than artificial, objects.
With artificial objects, (such as integers,)
we have access to essentially every pertanent fact
(Godel's Incompleteness Proof notwithstanding)@Foot<
This is not quite true -- there are various "meta-level" facts
about the integers which are not covered by the standard body of defining
facts.  For example, who first "discovered" them, or the contents of some early
theories about them, @i{etc}.>.
When talking about natural objects, like Arthur or democracy, however,
we are forced to deal with only an abstraction of the analogues --
that is, all we have is a partial description of the object.
Section @Ref[TorO] 
discusses why this observations leads to the need for reformulation.

Enough overview.
Below we consider what natural sounding ways of suggesting an analogy.
Each consitutes a description for constraining how these two things can
be analogous.
(Recall that, in many cases, these would not need to be stated explicitly;
this additional information can often be understood implicitly.)
The descriptions below can also be used to (partially) define the analogy --
that is, they can indicate how the analogues map into one another.
(Once again refer to Note @Ref[Gen-Use].)

@Comment{ Arthur/Beth cases }
Arthur is [just] like Beth
@BEGIN[ENUM1]
@ux<in that both are> lawyers.@*
@TAG[BothAre]
Or: @ux<as both are>, @ux<regarding both to be>, ...@*
@i{I.e.}: both are in the same category or class; and this comparison should
be based on this perspective.

@ux<in terms of> profession.@*
@TAG[TermsOf]
Or: "<Adjective>ily, A is like B", as in "Cognitively, people are like computers."@*
@i{I.e.}: both are in the same category, based on the <Adjective> perspective.

@ux<considering only their> height.@*
@TAG[Consider]
Or: @ux<based only on>, @ux<considering just>, 
@ux<where> X @ux<are the most salient attributes.>@*
@i{I.e.}: The value of their respective X slots [here height] are the same (or similar).

@ux<except that> Beth is female.@*
@TAG[Except]
Or: @ux<were it not that>, @ux<disregarding the fact that>, ... @*
@i{I.e.}: Some implicit, unstated slot [here gender] has a different value.

@ux<ignoring> gender.@*
@TAG[Ignore]
Or: @ux<excluding>, @ux<disregarding>, ... @*
@i{I.e.}: The value of their respective X slots [here gender] are different.

@ux<replacing> intelligence @ux<with> strength.@*
@TAG[SubstSlot]
Or: @ux<except in> X @ux<context rather than> Y, 
@ux<but deals with> X @ux<rather than> Y, ...@*
@i{I.e.}: There is a strong (@i{i.e.g.}, causal) reality to the 
proportional metaphor@*
@w<    >Arthur:Beth :: CalTech : Stanford@*
There is some relation joining Arthur to CalTech holds for Beth and Stanford.

@ux<after substituting> CalTech @ux<for> Stanford.@*
@TAG[SubstValue]
Or: @ux<except in> X @ux<context rather than> Y, 
@ux<but deals with> X @ux<rather than> Y, ...@*
@i{I.e.}: There is a strong (@i{i.e.g.}, causal) reality to the 
proportional metaphor@*
@w<    >Arthur:Beth :: CalTech : Stanford@*
There is some relation joining Arthur to CalTech holds for Beth and Stanford.

@ux<as> Prince Charming @ux<is to> Cinderella.@*
@TAG[As-Is-To]
Or: @ux<a la> Prince Charming @ux<with respect to> Cinderella, ...  @*
@i{I.e.}: (At least) one of the relations joining Prince Charming to Cinderella
links Arthur to Beth. Perhaps "loves enough to search for"?
(This is much like the case above.)

@END[ENUM1]

Notice that these @Ref[As-Is-To] cases can be divided into three general
categories.
Cases @Ref[BothAre], @Ref[TermsOf] and @Ref[Consider] are all "positive",
in that we are (indirectly) specifying the presence of some feature shared
by both analogues.
Next, cases @REF[Except] and @Ref[Ignore] both indicate some "negative" feature --
some property which only one of the analogues has (or is known to have).
Finally, cases @Ref[SubstSlot], @Ref[SubstValue] and @Ref[As-Is-To]
seems "substitutive" --
indicating that some feature which held for one analogue holds, 
@i{mutatis mutandis}, for the other.

@COMMENT{ Everything from Page 21 upto this Page 23 was copied from
	ANLGY.MSS[rdg,dbl] on 24-Nov-82 }
@SubHeading[What are other arguments to @i{Analogous}?]

Before presenting our view of analogy,
we will motivate it by "undermining the competition".

The next two chapters present the dominant views of analogy,
@i{viz.}, as a mapping, and as a commonality.
We will use the examples presented in this chapter to
illustrate the strengths and weaknesses of both of these approaches.
Each chapter will close with an evaluation of that perspective.
We will discuss which types of analogizing tasks this formalism
can and cannot handle,
and then describe how easy those attainable tasks are.

@Chapter[Mapping]
@Label[Map-Gen]

This chapter presents two views of analogy,
each based on mapping from one analogue to the other.
We will critique each approach seperately, (at the end of that section,)
and then conclude this chapter with some general reasons why
this mapping approach to analogy is inadequate.

@Section[Feature to Feature Mapping]
@Label[F-F]

This is the most common approach to analogy --
@i{A} and @i{B} are similar whenever their parts@Foot{
By "part" we are referring to some @i[part] of the description of the analogue,
not necessarily sub-pieces or components.
Hence a "part" of Arthur may be his Intelligence.
For our purposes, we think of any slot and value as a "part" of the concept.}
(or some relevant subset of them)
can be shown to correspond.
(This is verified by perusing @Cite[M&T],
and observing how many researches take this position.
See also the (non-AI) references @Cite[Hesse] and @Cite[Black];
and the AI @Cite[Evans], @Cite[Kling] and @Cite[Winston].)
The most straightforward way of encoding this uses the Unit/Slot/Value
notation, as discussed in @Cite[Frame].

This approach works nicely for many of the Arthur and Beth cases 
given in Section @Ref[InformalExs].
The Positive Cases are handled trivially.
The "@ux<both are>" case, (@Ref[BothAre]),
which claimed they both are lawyers,
is tantamount to noting that the value of their respective 
@i{Profession} slots agree --
@i{i.e.}, @b{Arthur}:@i{Profession} = @b{Beth}:@i{Profession},
both equal "Lawyer".
The "@ux<in terms of>" claim, (@Ref[TermsOf]:
in terms of sharing the same profession,) is even more obvious.

The values found need not be equal -- often similarity is sufficient.
(Of course this does lead a recursion...)
For example, Arthur and Beth might be considered analogous
because the respective ancestry was similar --
@BEGIN[Equation]
@TabClear
@B[Arthur]:@↑@I{AncestryFrom} = Romania
@B[Beth]:@\@I{AncestryFrom} = Hungary.
@END[Equation]
Now we have to show that Romania and Hungary are similar.
The similarity criteria for these values may be context dependent --
based on the different base units.
Note @Ref[ContextDep] discusses this point.

The Substitutive Cases seem to work well also
-- often requiring little more than a simple lexical substitution.
For example, one could handle the
"@ux<after substituting> CalTech @ux<for> Stanford" case
by scanning the @b[Beth] unit for the the value "Stanford", and replacing
all such values with "CalTech".
(It might require some other checks, which we won't discuss here.)

The negative cases,
"@ux<except that> Beth is female" and "@ux<ignoring> gender",
can also be fudged, by, once again, first noting where the value
and slot name, respectively, occur in the @b[Beth] unit, and 
then dealing with that slot/value situation accordingly.
One solution would involve mapping Female to Male;
another would be to simply disregard this @i{Gender} slot altogether.

Now consider how to apply this simple feature mapping approach to
the more formal cases, as examplified in Section @Ref[FormalExs].
As in that example,
these situations are often characterized by noting that both analogues 
contain similar embedded structures
-- similar in that each of these substructures satisfy a certain theory.
(In our example, we saw that
< @B[Z],@K[PlusSign],@i[0] > @K[AsymptLTE] @B[INTEGERS] and 
< @B[Q],@K[Times],@i[1] > @K[AsymptLTE] @B[RATIONALS],
and that both substructures satisfied the group theory@FOOT[
The @K[AsymptLTE] relation means embedded substructure, of course.].)

This analogy is quite difficult to state,
given the restriction that all we can state is that
the value of some slot of the @B[Integer] unit must be similar (or equal) to
the value of the same slot of the @B[Rational] unit.

There are convoluted approaches which would work:
Perhaps this @b[Integer] unit could have a @i{Contains-Structure} slot,
whose value includes (a pointer to) the @b[Integer@u{Qua}Group] unit.
This unit, in term, would have a @i{SatisfiesTheoryOf} slot,
whose value was GroupTheory.
Similarly @b[Rational]:@i{Contains-Structure} = @b[Rational@u{Qua}Group], and
@b[Rational@u{Qua}Group]:@i{SatisfiesTheoryOf} = GroupTheory.
Given this, one could see that @B[Integer] and @B[Rational] are analogous,
as their @i{Contains-Structure} slots have similar values -- that is,
each of those respective referenced to units have a
@i{SatisfiesTheoryOf} slot whose value is GroupTheory.

It was problems of this sort which lead to the next refinement of
this mapping approach, in which relations, as well as "values of slots"
could be mapped over.  This is presented in the next section.

In summary, we note that this feature mapping approach is quite useful,
and quite efficient, but does run into some problems.
Its limitations are, unfortunately, quite extensive.
While this approach could indeed find analogies based
on the "ground term constants", it has a hard time
comparing the non-binary relations (as shown above),
and is all-but-unable to actually deal with the arbitrary relations
which may involve the analogues.
In Section @Ref[S-M], we will discuss the limitations 
associated with (both instances of) the mapping approach to analogy,
as well as give reasons for the characteristics mentioned in this summary.

@Section[Symbol to Symbol Mapping]
@Label[S-S]

In this section we will extend the feature to feature mapping 
to the more general case where one can map a set of arbitrary propositions
(in which one of the analogues participates) into a corresponding set
which involves the other analogue.
Viewing slots as binary relations, we see that this approach is a
proper superset of the previous feature mapping approach.
There one can only map tertiary propositions whose first arguments matched,
and where the analogues were in the second position.
(@I{I.e.}, just cases where the values of slots changed.)

Here not only may the values of the slots be changed,
but we can deal with general (not just binary) relations.
In addition, we can map one relation (@i{nee} slots),
which deals with one analogue, onto another relation.
(This means we will need a second order system to do anything interesting,
of course.)
This permits us to discuss features of features -- for example, that the
Operation feature of @b[INTEGERS],
which is @K[PlusSign] in our example, is associative.

Many people have discussed (or built systems based on) this approach
-- including @Cite[Carbonella],
@Cite[Gentner], @Cite[GentnerA], and @Cite[InterField].

It is true that
any analogy one can describe using this generalized mapping approach can 
be described using the previous feature mapping approach,
given the appropriate set of features.
The advantage of this approach is perspecuity, in terms of number
(and naturalness) of symbols needed, elegance, etc.
Consider how trivial it is to encode the earlier
@i{Integers and Rationals are both groups} example,
given the relations
@BEGIN[Equation]
Satisfies(GroupTheory, <@B[Z], @i[+], @i[0]> )
Satisfies(GroupTheory, <@B[Q], @i[*], @i[1]> ).
@END[Equation]

The next section will discuss the limitations associated 
with this mapping approach to analogy; as well as repeat the advantages.

@Section[Summary of Mapping Approach]
@Label[S-M]

This section will describe many of the advantages and disadvantages associated
with this mapping approach to analogy.
First we will discuss how successful this mapping formalism is at
describing different types of analogizing tasks.
This will lead to a discussion of which tasks
(of the ones which could be stated within this mapping formalism,)
are easy to solve,
and then to tricks which can be employed to solve the other
(statable)
tasks.
After this we will mention various remaining aspects of this approach.

The mapping approach has many
(quite seductive)
advantages.  
First, this formalism is sufficient to describe almost any type of analogy task --
covering both "analogy finding" and "analogy using" categories.
Second, most of the "analogy use" tasks can be solved quickly and efficiently
-- many require only a relatively simple and straightforward matcher.
And finally, this simple matching seems to work for almost all cases
of the "find analogy" tasks as well.@FOOT[
As we will discuss later,
this success can be attributed to
the fact that the analogues have very accomodating representations,
one which often explicates the desired mapping.
This is, in turn, a by-product of the fact that
the person who describes the analogues
usually has a similar background to the person who will use these facts,
and so encodes these analogues in a way which makes the analogy transparent.
See discussion of reformulation, below.]
We will now elaborate these virtues.

@SubHeading[Description of tasks]
We consider first the @i[Analogy Finding] tasks:
@BEGIN[ITEM1]
"Find the analogy joining two analogues" is equivalent to finding a mapping
@G[s]: [features of analogue 1] @K[LeftArrow] [features of analogue 2].

"Find the other analogue" is equivalent to finding an object, @G[a]@-[2],
which embodies (satisfies) the facts in the range of
@G[s]@K[LeftDoubleBracket] @G[a]@-[1] @K[RightDoubleBracket].
(Recall that both @G[s] and @G[a]@-[1] are assumed given.)
@END[ITEM1]

This mapping formalism is even more adept at describing
a full range of @i[Analogy Using] tasks.
This is because the analogy itself is a well defined object
-- it is that mapping of (features of) one object onto 
(features of) the other.
This makes it relatively easy to analyze an analogy,
For example, one can describe the set of features which a
given analogy considers -- by listing the domain and range of the mapping.
Or one can (begin to) define the goodness of an analogy as a weighted
sum of the component associations.

One can also compare or rank analogies, by applying well-defined measurements
to these mapping.
For example, one analogy is more complete than another if the 
mapping of the first extends that of the second.
Similarly, with the proper measuring system
one decide which proposed analogy was most useful...

The most familiar "analogy use" task involves
conjecturing a new fact about (one of) the analogues.
This can be achieved by
extending the analogical mapping,
to now take additional parts/features/ ... of one analogue,
and map them into some correspondents in the other analogue.

@SubHeading[Difficulties]

While any of these tasks can be stated using this mapping formalism,
many are still is quite difficult to perform.
Consider first the "analogy finding" tasks --
in particular, the "find the analogical mapping, given the analogues" task.
Realize the approaches implied by this formalism
(two of which were discussed earlier in this chapter,)
provide no guidance in constructing the analogy.
That is,
the fact that we are seeking a mapping says nothing about the contents
of this mapping.
For example, at this level nothing precludes the possibility
that each fact about one analogue is mapped onto an arbitrary fact
about the other.
Clearly this is not what is intended by the term @i[analogy].
There should be some contraints on what features of the first analogue
should be mapped over,
and (possibly) other constraints which limit their image
-- i.e. the corresponding features of the second analogue.

To elaborate this, imagine constructing an analogy mapping between
@I[Analogue@-{1}] and @I[Analogue@-{2}].
What does it mean to say that the
@I[F@-{1}] feature of @I[Analogue@-{1}] should correspond to the
@I[F@-{2}] feature of @I[Analogue@-{2}].
All we know is that 
@I[F@-{1}] should be similar to @I[F@-{2}],
and that this new @I[F@-{1}] - @I[F@-{2}] correspondence should
extend the original @I[Analogue@-{1}] - @I[Analogue@-{2}] mapping.

What can we say about this extention?
First, the result must be a function,
and should be consistent@FOOT[whatever that means]
with the original map.
Beyond these "syntactic" constraints,
a good analogy should also be "semantically" meaningful.@FOOT{
<<is this relevant, here or later??>>
This often means that this transformation
was justified by some known fact or rule about the world.]
Finding @i[meaningful] extentions is what makes analogizing so tricky.}

The fact that most programs use a body of rules
to indicate what types of facts and features should be considered
does not obviate this problem.
What motivated those rules?
Clearly nothing intrinsic to the fact that this is a mapping.
(I.e. these rules can be viewed as embellishments to a mapping scheme,
but there are not needed to produce a mapping.)
The next chapter will discuss a different formalism of analogy
which supplies this "direction" needed to construct an analogy.

Consider now a different "analogy finding" task:
Imagine, instead, being given only one analogue
and a description of the desired analogy,
and asked to find the best analogue to fit this situation.
(E.g. find a legal case which ...)
It is not clear how to use the above mapping model of analogy for this purpose.

A final "analogy finding" task is the familiar case
-- asking how a collection of objects are all similar.
Given that this is NOT merely the O(n@+[2]) pairwise analogies,
it is apparent that there is no way to describe this case of analogy as
a mapping.

This covers the difficulties associated with "analogy finding" tasks.
"Analogy using" tasks seem both easy to state and relative easy to solve,
in the general case,
modulo the problems which the next topic, "Reformulation", will address below.

@SubHeading[Other Issues: Reformulation]

<<Merge this is:

consider analogy between two vectors: if they each have a zero coordinate.
But given ANY pair of vectors, we can transform cartesian system into an 
"equivalent" one in which this is true - so they are analogous.

Or switch from rectangular to polar coordinates to see relation between
circle and sphere --
when solving issue of "locus of points equidistant from a given center".
>>

Another issue, reformulation,
is, perhaps, the central problem of analogy understanding,
as is, at some level, independent of the formalism used to describe analogy.
However it plays such a prominent role in both defining and using a mapping
that this issue is best discussed here.
(That is, whle none of the approaches included in this paper 
will come close to resolving this problem, this mapping approach does the
worst.)

When we mentioned that the analogical mapping can be used to carry some 
fact about one analogue onto a corresponding fact about the other
it is usually assumed that these "facts" would be simple --
dealing with, say, a pair of constant symbols,
or some pair of propositions, which are of the same arity,
and usually employing the same relation symbol.
It is important to realize how crucial a role
the representations of the analogues played
in both defining the mapping and in using it.
(We were hinting at this way back in footnote @Ref[?].)
<<Here: give example -- #deaths in Hamlet, as a slot, helps.  Compare with
English text.  Or consider presense of term for ROOT of a tree...>>

Analogies, here, are very tied to the representation used.
If the analogues are not in correct form,
there is very little one can do.
However, realize that these features, ideally,
should depend on the analogues themselves,
and not on their representations.

<<here - expand this, perhaps>>

@SubHeading[Other Issues: Learning]

Another issue is learning.
The result of the analogy question is a rather specific mapping.
How could this information be used for some subsequent task?
As it deals so specifically with this pair of analogues, it is hard
to see how it could then be applied to a different situation.
This behavior does not fit well with the desired behavior of an analogy
understanding mechanism.

The underlying reason is that the "common features" 
which connect the analogues are never explicitly noted.
This means, first, that learning (as a side-effect) will not occur.
(That would be measured in terms of speed up of performance, or ...)
It also makes it impossible to create
an inventory of analogues,
(usually manifest as "commonalities",)
or to exploit an existing collection.
Such information, we will see in the next chapter, is very useful
in guiding the construction of other analogies.

Realize that an acknowledgement of the commonality of the analogues
is very much needed.  Here, it is just not explicated.

@SubHeading[Conclusion]

In a nutshell, we see that the mapping approach
is pretty good for tasks which involve using the analogy,
but provides little help for tasks which are attempting to find an analogy.

@Chapter[Commonality]
@Label[Common-Gen]

Notice that the analogies defined as a mapping in the previous chapter,
were based on the ways in which these two analogous @i[DIFFER].
This approach is, instead, explicitly capitalizes on the similarities
shared by the two analogues.
(In that sense it follows from the first mislabeled @T[Analogous] relation
discussed in Section @Ref[Informal].
We will henceforth refer to this weak binary relation as @T[Similarity].)

As with the previous chapter, we will consider two subcases of this approach.
These differ in how that common set of features will be stored
-- as a class or as a theory.
After presenting these two approaches we will summarize the merits and
shortcomings inherent in both manifestations of this 
@i[Commonality] view of analogy.

@Section[Common Theory]
@Label[CT]

Here we consider a model-theoritic approach to analogy,
where we consider two objects to analogous if there is some common theory
which each analogue satisfies.
(See definition given in @Cite[M&M].)
This would mean that the @T[Analogous] relation takes three arguments:
a pair of models, (@i[viz.], the analogues) and that common theory.@FOOT[
We will, for convenience, deal with theories written using the conventions
of Predicate Calculus, (PC).
There are many other formal representations which would do as well.
We chose PC, basically, because it comes with a 
well-understood (Tarskian) semantics,
and an accepted body of rules of inference.
Also, we are NOT limit ourselves to first order PC,
or to a calculus which lacks any explicit meta-level information --
in fact a good many of our rules are at those "higher" levels.]

For example, 
@BEGIN[Equation]
(Analogous @B[Z] @B[R] GroupTheory)
@END[Equation]
would be a true statement, as would
@BEGIN[Equation]
(Analogous "Arthur" "Beth" T@-[FM]),
@END[Equation]
where 
T@-[FM] includes facts like "@B[(MEM ** Lawyer)]",
with the understanding that the appropriate instantiation of "**"
is the individual Arthur in the case of the first model, and
Beth in the second case.

The summary section, @REF[S-C], will discuss many of the features,
both pro and con, will this commonality approach,
concentrating in particular on the types of tasks which this can be
described within this formalism.
The remainder of this section will discuss specific features of this
common theory approach.

<<rewrite this paragraph>>
Notice, on the positive side, that the two analogues need not be
be described in the same language --
the interpretation process associated with model-theoritic satisfaction
does all of these mappings.
While this does not solve the reformulation problem mentioned above,
(after all, one still has to describe the analogues in some manner,)
it does remove it one level.
Note that any two representations of an objects are, by this definition,
analogous.  This is NOT true under the mapping view of analogy.

This language independence is a double-edged sword.
One obvious problem is how to determine which terms in one
analogue correspond to which terms in the other.
(This is true for both analogy finding and analogy using tasks,
as neither case (explicitly) includes the pair of instantiation mappings.)

@Section[Common Class]
@Label[CC]

This approach is almost identical to the prior Common Theory case.
Here, instead of satisfying a common theory,
two analogues are deemed analogous if they belong to the same set --
i.e. if they both satisfy the same unary predicate,
denoting the characteristic function of that set.
The equivalancy is apparent when spelling out the terms for membership
in this set 
-- which may be only when some arbitrary formula is true for that object.

For example, we may consider @T[Arthur] and @T[Beth] to be analogous as
they are both lawyers -- i.e. 
@T[Lawyer(Arthur)] and @T[Lawyer(Beth)] are both true.
This is clearly isomorphic to the
@T[(MEM ** Lawyer)] case used in the common theory situation.

As a more complicated example, suppose we observed that
@T[Arthur] and @T[Beth] were analogous as they both attended a good school.
Here we would write that
@T[AttendedGoodSchool(Arthur)] and @T[AttendedGoodSchool(Beth)] are both true,
where
@BEGIN[Equation]
AttendGoodSchool(x) @K[IFF] @K[Exists] s. [Attend(x,s) @K[AND] GoodSchool(s)].
@END[Equation]
In the earlier case, we would have defined a AGS theory, which consists of
the sentences
@BEGIN[Equation]
Attend(** GS)
GoodSchool(GS)
@END[Equation]
where the symbols @T[**] and @T[GS] denote constants, which are instantiated
by @T[Arthur] and @T[CalTech] in the case of the first analogue; and
by @T[Beth] and @T[Stanford] in the other case.
Notice we had to generate skolem variables, in both cases --
the "s" in the current Common Class case, and that "GS" constant
when dealing with a common theory.

This remainder of this section will describe aspects on
this "Common Class" formalism,
concentrating on how it differs from its sibling, the "Common Theory" approach.

First, the common class does not need to pre-defined,
any more than the common theory has to already exist before we could
instantiate it to the two models.
Second, class membership is encoded using the characteristic predicate
of this set,
which has some associated "semantics" --
that defining sentence which follows the @K[IFF] sign above.

When we want to discuss a complex relation 
-- as @T[AttendedGoodSchool] was --
we are forced to discuss its parts or "sub-features".
This is easy, using the "skolem" functions shown above.
(Recall that, again,
the CT approach requires something isomorphic to this as well.)
While this seems, somehow, unclean, it does seem 
sufficient to handle any situation.

One place where CC differs from CT is in terms of the language used
to describe the analogical connection.
(e.g. the "as both are @i[x]", or "except that it is @i[y]", ...)
Both analogues must be described in the same language -- as
both must satisfy the same predicate.
Hence the problems associated with having different languages do not arise.
Of course, neither do its advantages --
especially wrt reformulation, and general versatility.

Also, everything which can be stated (is forced to be) in first order PC,
i.e. avoiding the hassles associated with meta-level.
(And, again, providing none of the advantages either.)
@Section[Summary of Commonality Approach]
@Label[S-C]

Before listing the types of tasks which can be tackled using this formalism,
we will first discuss some other comments about this commonality approach.
First, it clearly is a nice extension to the notion of @i[Similarity] --
once again we are discussing just how two objects are similar.
Second, here it is possible to maintain a collection of to be considered
analogies, which can guide analogy generate tasks.
<<here - anything else?>>

@SubHeading[Description of task]

Both commonality formalisms,
(like the earlier mapping approach,)
are capable of describing almost any analogy task.
Most "analogy using" tasks are easily stated,
as the analogy itself is quite explicit -- it is that common theory,
or predicate.
Thus we can readily compare two analogies,
and as readily define measures for evaluating how good an analogy is.

The other standard "analogy use" task is deriving new facts about
one of the analogues.
By force of the definition of analogy,
each analogue must satisfy a certain theory or predicate.
This means that we can produce the precise (set of) sentences which 
the unfamiliar analogue --
those facts which follow from instantiating that common theory or
which must be true for the common predicate to be satisfied.
Hence we can explicitly state what facts @i[must] be true for this analogue.
Beyond these guaranteed statements,
we can go on conjecture other facts, based on these now-given facts.
<<Here - give an example>>
Finally, realize that these manipulations reduce to well defined PC inference
methods -- such as instantiation, or satisfaction.

What about "analogy finding" tasks?
Consider first the "find the other analogue" case.
This is relatively easy, requiring only that we find some model for a theory
within some domain, where that theory is the analogy, and the domain comes
from the "analogizing" context.
Notice that the first analogue appears to play no role in this situation.

The "generate the common theory from the analogues" problem is also
easy to state.  It is, however, harder to solve.

@SubHeading[Difficulties]

Consider our canonical "A is like B within constraint @G[a]",
and imagine how to generate the theory which both A and B will have
to satisfy.
(As the common predicate case is essentially identical to this, we will
not deal with it as well.)

It is easy when this @G[a] is a positive instance.
This means that both analogues must satisfy some property,
e.g. "both are lawyers", or "in terms of profession".
Here the common theory just includes that common statement.
<<here: two notes:
(1) may have to abstract the particular relation
	[tree case]
(2) may have to then propagate the effects of this.>>

"Negative instances", 
which specify that something is NOT true for one analogue,
is more difficult.
The trick is to specify, in meta-theory,
what relations are to included, and which excluded,
from sentences which can appear in this common theory.
The "excluding gender", or "except that he is male" cases
can be solved by declaring that the "Gender" relation must not appear in
the common theory.

"Substitutive cases",
such as the "after substituting CalTech for Stanford" example,
seem impossible to state in this formalism.
How can a single theory indicate a pair of things,
where exactly one is true of each analogue.

@SubHeading[Other Issues: Learning]

The fact that one can accumulate a host of common theories is
another advantage to this approach.
This inventory can provides some direction for finding the analogy.

One may have some general "abstractions" ...
(More on this in general comments re: Commonality.)

It is because there 
are some general rules about the world which can be exploited,
that this formalism for analogy makes any sense.

@SubHeading[Other Issues: Correspondences]

The remaining problem is how to establish the correspondences.
To what does the x of A map?  
While this information is part and parcel to the other approach, mapping,
here the information is unavailable.
<<here - give an example>>

@SubHeading[Other Issues: Reformulation]
<<Here - mention that this remains an issue>>

@SubHeading[Conclusion]

Here the analogy use task are rather straightforward,
as we again have an explicit handle on the analogy itself.
Tasks which require the analogy to be found, or generated,
vary considerably in difficulty, depending on the nature of the constraint.
Note that "analogy finding" is here defined -- it is possible to have
a catalogue of known analogies, and use this to find the analogy.
(Recall every mapping had to be generated.)

@COMMENT{ Everything from Page 19 upto this Page 30 was copied from
	ANLGY.MSS[rdg,dbl] (pages 12-23) on 24-Nov-82 }
@Chapter[Answer: Common theory + Mappings]
@Label[Answer]

Our solution involves taking the best from both worlds --
the idea of mappings remains, as does the notion of capturing a commonality.
Here the analogy relation takes five arguments:
in addition to the pair of analogues themselves,
(or more precisely, a pair of descriptions of those objects,)
this proposition will include a common theory, (which both analogues "satisfy"),
and a pair of mappings, which each map sentences from that common theory to each
analogue theory.

Note this permits us to include both the similarities of the analogues
(using the common theory) and their differences -- stored by noting what
maps to what.

<<here>>
Before presenting more details of "the answer",
we will mention ...
After those details
we will illustrate that this does seem to cover all the situations we
have seen thus far.

Can't really claim to be new 
-- this is related to the idea of finding a sibling on the "generalization"
tree -- found by first generalizing one analogue, and then specializing.
That generalization is (isomorphic to) the CT, the generalization process is
@g{s}@-{1}, and the specialization is 
@g{s}@↑@-{2}@\@+{-1}.  
(Our version is a more symmetric version.)
@i{C.f.} @Cite[Polya1], p.16.

@Chapter[Remaining Issues]
@Label[Issues],

 mapping sentence to sentence
  A. Symbol to Symbol doesn't work 
    i. Examples:
	[Take ON2 vs ON3 case]
    ii.  Soln: sentence to sentence mapping
	Still, want some notion of consistency
	Standard recursive decomposition not adequate
  B. Satisfies desired propoperties of analogy?
	[here list some props, and show that it does.]

Problem:
Where is the analogy?  How to compare two analogies -- there is no single
thing, like a theory or a mapping, to grab onto...

Seeing that the previous approaches were lacking,
we conclude that, to be adequate, the analogy relation must have five terms --

@SubHeading[Critique]

Solves instantiation issue, and hence leads to mappings (see Chapter @Ref[F-F].)
Symbol-Symbol doesn't work -- see next section)


Difficult to compare analogies -- as may be totally different.
(This just stems from added complexity, and may not be part and parcel
of ...)
Can handle both finding and usage of analogy -- by two parts.

needs sentence to sentence mapping
	Here want to have some notion of consistency
	Standard decomposition not adequate
Define
@BEGIN[Equation]
ANALOGY( A@-{1}, A@-{2}, CT, @g{s}@-{1}, @g{s}@-{2} ) @K[IMPLIES]
   @↑CT @K[NEQ] @K[EMPTYSET] @K[AND]
@\CT @K[SUBSET] ( @g{s}@-{1}[ A1 ] @K[INTERSECTION] @g{s}@-{2}[ A2 ]) @K[AND]
@\CONSIST-PRESERVE( @g{s}@-{1} ) @K[AND]
@\CONSIST-PRESERVE( @g{s}@-{2} )
@END[Equation]
where @g{s}@-{1}, @g{s}@-{2} are partial mappings, and
CONSIST-PRESERVE( @g{s}) means
@BEGIN[Equation]
@K(ForAll) X. CONSIST( X ) @K[Implies] CONSIST( @g{s} ),
@END[Equation]
where @T[CONSIST(X)] means the theory @T[X] is consistent.
Also, @T[CT], @T[A@-{1}] and @T[A@-{2}] are all theories.

Perhaps add in something like @T[Satisfies( Model(A@-{1}), CT)]? or whatever.

  We want to impose further restrictions on @g{s}@-{1}, to prevent them from mapping
  non-tautalogies into tautalogies, etc.  (Currently on sentence-sentence)
  And what else?

------
Satisfies properties of analogy?

Does Analogical inference have to be meta-level?  Sure seems that way.

Currently:
@BEGIN[Equation]
@B[Given:] @↑Analogues a and b (and A@-{2} @K[Eq] Th'(b)]
@\A@-{1} = Th'(a) 
@\B which is B @K[SubSet] A@-{2}
@\Similar( a,b )
@B[Find:]@\@G[t] @K[MemberOf] A@-{2} @K[MinusSign] B ... i.e. new fact about B, ...
@END[Equation]
where @↑Th'(@g[a]) = axioms of @g[a], but NOT their deductive closure;@*
and @\Similar( a,b ) @K[IFF] @K[Exists] CT, @g{s}@-{1}, @g{s}@-{2}.@~
Analogy( Th(a), Th(b), CT, @g{s}@-{1}, @g{s}@-{2} )

A basic intermediate step is
@BEGIN[Equation]
Analogous( A@-{1}, A@-{2}, CT, @g{s}@-{1}, @g{s}@-{2} )
@G[t] @K[MemberOf] CT
-----------
@g{s}@-{1}( @G[t] ) @K[MemberOf] A1
@END[Equation]

Hence
@BEGIN[Equation]
Analogous( A@-{1}, A@-{2}, CT, @g{s}@-{1}, @g{s}@-{2} )
@G[t] @K[MemberOf] A@-{1}
-----------
@g{s}@!@-{2}@/@+{-1}[ @g{s}@-{1}( @G[t] )] @K[MemberOf] A2
@END[Equation]

where @g{s}@!@-{2}@/@+{-1} is inverse of @g{s}@-{2}.

@Chapter[Acknowledgements]

Our (respective) advisor and ?collaborator? Prof Douglas Lenat.
Thanks to Prof Lindley Darden,
and useful comments from
Tom Dietterich,
Patricia Schooley,
and Steve Tappel.
@CHAPTER[Notes]

@BEGIN[ENUMERATE]

@BEGIN[Multiple]
@Tag[Gen-Use]
This side comment is addressed to those "procedural-ists" who regard an analogy
as a process which takes some inputs and returns some output:
It is very tempting to split the types of analogizing tasks into two partitions --
those which generate/specify an analogy, 
(@i[e.g.], those programs which generate the desired mapping,)
and those which use or understand the analogy -- for example, those programs
which use the given analogy (perhaps the mapping)
to further specify some property of one (or both) of the analogues.

For illustration, consider the following extreme examples: 
@BEGIN[Equation]
"How is @↑learning at CalTech like
@\sipping water from a fire hose?"
@END[Equation]
is clearly in the first camp.
The goal here is to specify that feature which is common
to both @i["learning at CalTech"] and @i["sipping water from a fire hose"]
analogues --
perhaps that, in both cases, a vast amount of material is being forced into
the student/drinker at a flowrate far beyond his capability to absorb it.
At the other end of this spectrum,
@BEGIN[Equation]
"Electricity is like Water flow in that both involve the
movement of some material through some specified course"
@END[Equation]
fits nicely into the second category.
Here the analogy is quite well defined; the challenge is to
determine new properties from the Electricity analogue, based on both
facts known about Water Flow, and about the well-specified connection --
that both involve movement of something along a course.

We will see later that this distinction between analogy-specification
and analogy-use is usually fuzzy; if not altogether meaningless.  
In @Cite[NaiveAnalogy] I conjecture that 
both analogy generation and analogy use/understanding
should come under heading of analogy refinement.
End of digression.
@END[Multiple]

@BEGIN[Multiple]
@TAG[Dims]
One can think of each of these cases as a point in the two dimensional space,
whose axes are:
@BEGIN[ITEMIZE]
The "Formal"ness of this Analogy,@*
measured by determining how many of the analogues (0, 1 or 2)
are formal, (as opposed to natural,) objects.

"Pre-existence" of the (common) theory,@*
That is, whether the hearer was aware of the underlying unity of the
two analogues before presented with this analogy.
@END[ITEMIZE]
The examples given in Chapter @Ref[Examples] should help elucidate
these dimensions.
@END[Multiple]

@TAG[ContextDep]
Determining this similarity might involve various contextual considerations.
Hearing that "Fred is like Jill in that both are tall."
does not mean that @b{Fred}:@i{Height} = @b{Jill}:@i{Height},
as Tall for men has a different meaning (in terms of absolute meters) than
Tall does for women.
(Of course, this @i{Height} slot records the absolute height of the individual in,
say, meters).
What we really meant was that their respective @i{QualitativeHeight} slots
match -- as both have the value Tall.
The particulars (@i{i.e.}, cutoff values)
used to compute this value will be different for men than for women.
@END[ENUMERATE]

@Unnumbered[References]
@Bibliography